Systems and methods for medical dispensing, management and monitoring

ABSTRACT

The present disclosure relates to a system for medical dispensing, management and monitoring. According to one aspect, a remote medical management environment can include a medical management system intermediary to a plurality of patients and a plurality of medical care providers. The medical management system can communicate with medical dispensing devices configured to dispense medication to patients. Further, the medical management system can communicate with provider devices through which medical care providers can access medicine related information of patients and provide instructions, which can administer treatment protocols to patients of the medical dispensing devices. The remote medical management environment can allow medical care providers, such as doctors, the ability to remotely manage and administer medications to patients, while at the same time, avoid accidental medicinal drug use and abuse by patients.

RELATED APPLICATION

The present application claims priority to and the benefit of U.S.Provisional Application No. 62/118,341, titled “Systems and Methods forMedical Dispensing, Management and Monitoring” and filed on Feb. 19,2015, which is incorporated herein by reference in its entirety for allpurposes.

FIELD OF THE DISCLOSURE

The present application relates generally to systems and methods formedical dispensing, management and monitoring, and more particularly, tomethods and systems for providing medical care providers the ability toremotely manage and monitor the administering of medications to patientsvia remotely controlled medical dispensing devices.

BACKGROUND

Patients in need of medication either have to visit pharmacies to pickup medication or have the medicines delivered to them. Oftentimes,doctors treating these patients are unable to gauge the efficacy of themedications they prescribe until the patient either returns to theclinic for follow up testing or goes to a laboratory for blood work.

SUMMARY

The present disclosure relates to systems and methods for medicaldispensing, management and monitoring. According to one aspect, a remotemedical management environment can include a medical management systemintermediary to a plurality of patients and a plurality of medical careproviders. The medical management system can communicate with medicaldispensing devices configured to dispense medication to patients.Further, the medical management system can communicate with providerdevices through which medical care providers can access medicine relatedinformation of patients and provide instructions, which can administertreatment protocols to patients of the medical dispensing devices. Theremote medical management environment can allow medical care providers,such as doctors, the ability to remotely manage and administermedications to patients, while at the same time, avoid medicinal drugabuse by patients.

The medical management system can include a processor and a memoryincluding instructions configured to cause the medical management systemto allow a medical care provider to remotely manage and administermedications to one or more patients. The medical management systemincludes a patient database, a provider database, a medical manager anda prescription manager. The medical management system can include one ormore communication modules through which the medical management systemcan communicate with patient devices and provider devices.

The patient device, otherwise referred to as a medical dispensing devicecan be configured to allow a medical care provider, for example, adoctor, the ability to remotely monitor, regulate and manipulatemedication administration to a patient associated with the patientdevice. Through the medical dispensing device, the medical care providercan adjust either the dosage of medications or the time at which themedication is administered. In some implementations, the medical careprovider may receive feedback through the medical dispensing device orother medical device monitoring the patient and adjust the dosage ortime at which to administer medication based on the received feedback.The medical dispensing device can be equipped with a communicationsmodule that is configured to communicate with the medical managementsystem through which the medical care provider can remotely communicatewith the medical dispensing device. The communications module caninclude both hardware and software components that allow the medicaldispensing device to receive and transmit instructions and information.In some implementations, the communications module can be configured toprovide wireless communications, for example, BLUETOOTH, WiFi, cellularcommunications, among others. In some implementations, thecommunications module can be configured to communicate with anotherdevice, such as a smartphone, tablet, or other device that allows themedical dispensing device to receive and execute instructions receivedfrom the medical care provider. The medical dispensing device caninclude one or more electronic actuators that can be configured orprogrammed to control the amount of medication dispensed from themedical dispensing device.

In some implementations, the medical dispensing device is programmableand capable of maintaining activity logs. The activity logs can identifya date and time at which medication was dispensed, a dosage ofmedication dispensed as well as any other physiological measurements,for example, temperature, pulse, heart rate, blood pressure, sugarlevels, among others, taken around the time the medication wasdispensed. In addition to medication dispensing related activity, theactivity logs can identify when a medical care provider communicatedwith the medical dispensing device. In some implementations, theactivity logs can include information related to dosage changes as wellas changes in the time at which medication is to be administered.

The medical dispensing device can also include sensors measuring aquantity of medication remaining in the medical dispensing device. Insome implementations, the medical dispensing device an determine anamount of medication remaining in the medical dispensing device based onthe amount of medication included in a medicine cartridge and an amountof medication already dispensed since the medicine cartridge was firstinserted. The medical dispensing device can be configured to communicatemedicine quantity levels such that refills can be ordered before themedicine cartridge is completely empty.

The medical dispensing device can be tamper proof. This is to preventmedication abuse and fraud. In some implementations, the medicaldispensing device can include an alert system that triggers an alertupon determining that the medical dispensing device has been tampered oran attempt to tamper the medical dispensing device was made. In someimplementations, the medical dispensing device can include one or moresecurity modules. The security modules can include hardware and softwareto ensure that the medication is dispensed to an authorized user orpatient. In some implementations, the medical dispensing device caninclude a user recognition or identification system. In someimplementations, the medical dispensing device can include a fingerprintreader, an iris scanner, or any other biometric scanner to confirm theidentity of the user. In some implementations, the medical dispensingdevice can be password protected. In some implementations the medicaldispensing device can only be actuated via a second device, such as asmartphone or tablet, registered with the medical management system.

In some implementations, the medical dispensing device can include atemperature control module to control the temperature of medicationwithin the medical dispensing device. In this way, if the medicine inthe medical dispensing device is to be maintained at a particulartemperature, and the medical dispensing device is in a location that hasan ambient temperature much higher than the temperature at which tomaintain the medicine, the medical dispensing device can provide coolingto the medication. Conversely, the medical dispensing device can provideheating to medications that are supposed to be stored or maintained attemperatures higher than the ambient temperature at which the medicaldispensing device is located.

In some implementations, the medical dispensing device can be aprogrammable, remotely controlled prescription drug bottle. The medicaldispensing device may include Bluetooth, RFID, GPS, a battery, acontroller, a cellular chip, etc. The medical dispensing device coulddispense pills, liquid, powder, any vaporizable substance, collectively,respectively, and independently. The medical dispensing device can beconfigured to provide the ability to remotely regulate, monitor, controland/or verify dosage. In this way, a medical care provider can regulateor control the number of pills dispensed, the time at which they aredispensed and the location at which they can be dispensed, among others.For instance, if the pills can only be dispensed within a particulargeographic location identifiable via cellular triangulation techniques,IP addressing, or GPS coordinates, the risk of drug abuse, theft,resale, and redistribution can be minimized. In some implementations,the medical dispensing device can be configured to only dispensemedications when it is within a few feet from a stationary object, suchas a RFID scanner or Bluetooth source that may be tied to a particularlocation.

In some implementations, the medical dispensing device may be configuredto communicate with a mobile device of the patient to verify theidentity of a person accessing or requesting access to the medicaldispensing device. For instance, the medical dispensing device may onlydispense medication in response to receiving a communication or signalfrom a paired mobile device that can generate the communication orsignal upon verifying the identity of the patient. In someimplementations, the mobile device can verify the identity of thepatient through facial recognition, fingerprint scanning, passwords, orother security measures that can be received, identified or otherwiseincorporated via the mobile device. In this way, there is no need forthe medical dispensing device to be designed with an integratedfingerprint scanner, camera to detect facial recognition, or keypad toreceive a password from the patient, thereby reducing manufacturingcosts of the medical dispensing device.

In some implementations, the location of the medical dispensing deviceor the mobile device with which the medical dispensing device cancommunicate may be monitored. In some implementations, the medicaldispensing device can restrict the dispensing of medications based onone or more predetermined locations. In some implementations, one ormore location based policies can be established to ensure additionalsecurity. For instance, the medical dispensing device may be configuredto only dispense the medicine at predetermined locations, for example, apatient's home, a patient's work location, a nursing home, a hospital orother medical care provider's address, among others. In this way, if thedevice is stolen or otherwise provided to an unauthorized user, theunauthorized user may be unable to receive medication from the medicaldispensing device at locations different from the predeterminedlocations. In addition, the medical dispensing device may only transmitor receive data from the medical management system at the predeterminedlocations to reduce security breaches.

In some implementations, the medical dispensing device can operate usingbatteries. In some implementations, the batteries may be rechargeable ordisposable. In some implementations in which the batteries arerechargeable, the batteries may be charged via a USB cable, via a powersupply channel, or via wireless induction. In some implementations, toimplement wireless induction, the medical dispensing device can beincorporated with a wireless charging coil, for example, a wirelesscharging coil supplied by DIGIKEY and manufactured by Wurth Electronics,Inc. In some implementations, the wireless charging coil can be PartNumber 76030811, manufactured by Wurth Electronics, Inc. The shape, sizeand position of the one or more wireless charging coils can be designedto fit within the medical dispensing device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a block diagram depicting an embodiment of a networkenvironment comprising local devices in communication with remotedevices.

FIGS. 1B-1D are block diagrams depicting embodiments of computers usefulin connection with the methods and systems described herein.

FIG. 2 is a block diagram depicting a medical management environmentincluding a medical management system intermediary to a plurality ofprovider devices and patient devices.

FIG. 3 is a block diagram depicting a patient device configured todispense medication to a patient.

FIG. 4 is a block diagram depicting a provider device configured toallow a medical care provider to manage medications of patientsreceiving medication through the patient device of FIG. 3.

DETAILED DESCRIPTION

For purposes of reading the description of the various embodimentsbelow, the following descriptions of the sections of the specificationand their respective contents may be helpful:

Section A describes a network environment and computing environmentwhich may be useful for practicing embodiments described herein.

Section B describes embodiments of systems and methods for medicaldispensing, management and monitoring.

A. Computing and Network Environment

In addition to discussing specific embodiments of the present solution,it may be helpful to describe aspects of the operating environment aswell as associated system components (e.g., hardware elements) inconnection with the methods and systems described herein. Referring toFIG. 1A, an embodiment of a network environment is depicted. In briefoverview, the network environment includes one or more clients 102 a-102n (also generally referred to as local machine(s) 102, client(s) 102,client node(s) 102, client machine(s) 102, client computer(s) 102,client device(s) 102, endpoint(s) 102, or endpoint node(s) 102) incommunication with one or more servers 106 a-106 n (also generallyreferred to as server(s) 106, node 106, or remote machine(s) 106) viaone or more networks 104. In some embodiments, a client 102 has thecapacity to function as both a client node seeking access to resourcesprovided by a server and as a server providing access to hostedresources for other clients 102 a-102 n.

Although FIG. 1A shows a network 104 between the clients 102 and theservers 106, the clients 102 and the servers 106 may be on the samenetwork 104. In some embodiments, there are multiple networks 104between the clients 102 and the servers 106. In one of theseembodiments, a network 104′ (not shown) may be a private network and anetwork 104 may be a public network. In another of these embodiments, anetwork 104 may be a private network and a network 104′ a publicnetwork. In still another of these embodiments, networks 104 and 104′may both be private networks.

The network 104 may be connected via wired or wireless links. Wiredlinks may include Digital Subscriber Line (DSL), coaxial cable lines, oroptical fiber lines. The wireless links may include BLUETOOTH, Wi-Fi,Worldwide Interoperability for Microwave Access (WiMAX), an infraredchannel or satellite band. The wireless links may also include anycellular network standards used to communicate among mobile devices,including standards that qualify as 1G, 2G, 3G, or 1G. The networkstandards may qualify as one or more generation of mobiletelecommunication standards by fulfilling a specification or standardssuch as the specifications maintained by International TelecommunicationUnion. The 3G standards, for example, may correspond to theInternational Mobile Telecommunications-2000 (IMT-2000) specification,and the 1G standards may correspond to the International MobileTelecommunications Advanced (IMT-Advanced) specification. Examples ofcellular network standards include AMPS, GSM, GPRS, UMTS, LTE, LTEAdvanced, Mobile WiMAX, and WiMAX-Advanced. Cellular network standardsmay use various channel access methods e.g. FDMA, TDMA, CDMA, or SDMA.In some embodiments, different types of data may be transmitted viadifferent links and standards. In other embodiments, the same types ofdata may be transmitted via different links and standards.

The network 104 may be any type and/or form of network. The geographicalscope of the network 104 may vary widely and the network 104 can be abody area network (BAN), a personal area network (PAN), a local-areanetwork (LAN), e.g. Intranet, a metropolitan area network (MAN), a widearea network (WAN), or the Internet. The topology of the network 104 maybe of any form and may include, e.g., any of the following:point-to-point, bus, star, ring, mesh, or tree. The network 104 may bean overlay network which is virtual and sits on top of one or morelayers of other networks 104′. The network 104 may be of any suchnetwork topology as known to those ordinarily skilled in the art capableof supporting the operations described herein. The network 104 mayutilize different techniques and layers or stacks of protocols,including, e.g., the Ethernet protocol, the internet protocol suite(TCP/IP), the ATM (Asynchronous Transfer Mode) technique, the SONET(Synchronous Optical Networking) protocol, or the SDH (SynchronousDigital Hierarchy) protocol. The TCP/IP internet protocol suite mayinclude application layer, transport layer, internet layer (including,e.g., IPv6), or the link layer. The network 104 may be a type of abroadcast network, a telecommunications network, a data communicationnetwork, or a computer network.

In some embodiments, the system may include multiple, logically-groupedservers 106. In one of these embodiments, the logical group of serversmay be referred to as a server farm 38 or a machine farm 38. In anotherof these embodiments, the servers 106 may be geographically dispersed.In other embodiments, a machine farm 38 may be administered as a singleentity. In still other embodiments, the machine farm 38 includes aplurality of machine farms 38. The servers 106 within each machine farm38 can be heterogeneous—one or more of the servers 106 or machines 106can operate according to one type of operating system platform (e.g.,WINDOWS NT, manufactured by Microsoft Corp. of Redmond, Wash.), whileone or more of the other servers 106 can operate on according to anothertype of operating system platform (e.g., Unix, Linux, or Mac OS X).

In one embodiment, servers 106 in the machine farm 38 may be stored inhigh-density rack systems, along with associated storage systems, andlocated in an enterprise data center. In this embodiment, consolidatingthe servers 106 in this way may improve system manageability, datasecurity, the physical security of the system, and system performance bylocating servers 106 and high performance storage systems on localizedhigh performance networks. Centralizing the servers 106 and storagesystems and coupling them with advanced system management tools allowsmore efficient use of server resources.

The servers 106 of each machine farm 38 do not need to be physicallyproximate to another server 106 in the same machine farm 38. Thus, thegroup of servers 106 logically grouped as a machine farm 38 may beinterconnected using a wide-area network (WAN) connection or ametropolitan-area network (MAN) connection. For example, a machine farm38 may include servers 106 physically located in different continents ordifferent regions of a continent, country, state, city, campus, or room.Data transmission speeds between servers 106 in the machine farm 38 canbe increased if the servers 106 are connected using a local-area network(LAN) connection or some form of direct connection. Additionally, aheterogeneous machine farm 38 may include one or more servers 106operating according to a type of operating system, while one or moreother servers 106 execute one or more types of hypervisors rather thanoperating systems. In these embodiments, hypervisors may be used toemulate virtual hardware, partition physical hardware, virtualizephysical hardware, and execute virtual machines that provide access tocomputing environments, allowing multiple operating systems to runconcurrently on a host computer. Native hypervisors may run directly onthe host computer. Hypervisors may include VMware ESX/ESXi, manufacturedby VMWare, Inc., of Palo Alto, Calif.; the Xen hypervisor, an opensource product whose development is overseen by Citrix Systems, Inc.;the HYPER-V hypervisors provided by Microsoft or others. Hostedhypervisors may run within an operating system on a second softwarelevel. Examples of hosted hypervisors may include VMware Workstation andVIRTUALBOX.

Management of the machine farm 38 may be de-centralized. For example,one or more servers 106 may comprise components, subsystems and modulesto support one or more management services for the machine farm 38. Inone of these embodiments, one or more servers 106 provide functionalityfor management of dynamic data, including techniques for handlingfailover, data replication, and increasing the robustness of the machinefarm 38. Each server 106 may communicate with a persistent store and, insome embodiments, with a dynamic store.

Server 106 may be a file server, application server, web server, proxyserver, appliance, network appliance, gateway, gateway server,virtualization server, deployment server, SSL VPN server, or firewall.In one embodiment, the server 106 may be referred to as a remote machineor a node. In another embodiment, a plurality of nodes 290 may be in thepath between any two communicating servers.

Referring to FIG. 1B, a cloud computing environment is depicted. A cloudcomputing environment may provide client 102 with one or more resourcesprovided by a network environment. The cloud computing environment mayinclude one or more clients 102 a-102 n, in communication with the cloud108 over one or more networks 104. Clients 102 may include, e.g., thickclients, thin clients, and zero clients. A thick client may provide atleast some functionality even when disconnected from the cloud 108 orservers 106. A thin client or a zero client may depend on the connectionto the cloud 108 or server 106 to provide functionality. A zero clientmay depend on the cloud 108 or other networks 104 or servers 106 toretrieve operating system data for the client device. The cloud 108 mayinclude back end platforms, e.g., servers 106, storage, server farms ordata centers.

The cloud 108 may be public, private, or hybrid. Public clouds mayinclude public servers 106 that are maintained by third parties to theclients 102 or the owners of the clients. The servers 106 may be locatedoff-site in remote geographical locations as disclosed above orotherwise. Public clouds may be connected to the servers 106 over apublic network. Private clouds may include private servers 106 that arephysically maintained by clients 102 or owners of clients. Privateclouds may be connected to the servers 106 over a private network 104.Hybrid clouds 108 may include both the private and public networks 104and servers 106.

The cloud 108 may also include a cloud based delivery, e.g. Software asa Service (SaaS) 110, Platform as a Service (PaaS) 112, andInfrastructure as a Service (IaaS) 114. IaaS may refer to a user rentingthe use of infrastructure resources that are needed during a specifiedtime period. IaaS providers may offer storage, networking, servers orvirtualization resources from large pools, allowing the users to quicklyscale up by accessing more resources as needed. Examples of IaaS includeAMAZON WEB SERVICES provided by Amazon.com, Inc., of Seattle, Wash.,RACKSPACE CLOUD provided by Rackspace US, Inc., of San Antonio, Tex.,Google Compute Engine provided by Google Inc. of Mountain View, Calif.,or RIGHTSCALE provided by RightScale, Inc., of Santa Barbara, Calif.PaaS providers may offer functionality provided by IaaS, including,e.g., storage, networking, servers or virtualization, as well asadditional resources such as, e.g., the operating system, middleware, orruntime resources. Examples of PaaS include WINDOWS AZURE provided byMicrosoft Corporation of Redmond, Wash., Google App Engine provided byGoogle Inc., and HEROKU provided by Heroku, Inc. of San Francisco,Calif. SaaS providers may offer the resources that PaaS provides,including storage, networking, servers, virtualization, operatingsystem, middleware, or runtime resources. In some embodiments, SaaSproviders may offer additional resources including, e.g., data andapplication resources. Examples of SaaS include GOOGLE APPS provided byGoogle Inc., SALESFORCE provided by Salesforce.com Inc. of SanFrancisco, Calif., or OFFICE 365 provided by Microsoft Corporation.Examples of SaaS may also include data storage providers, e.g. DROPBOXprovided by Dropbox, Inc. of San Francisco, Calif., Microsoft SKYDRIVEprovided by Microsoft Corporation, Google Drive provided by Google Inc.,or Apple ICLOUD provided by Apple Inc. of Cupertino, Calif.

Clients 102 may access IaaS resources with one or more IaaS standards,including, e.g., Amazon Elastic Compute Cloud (EC2), Open CloudComputing Interface (OCCI), Cloud Infrastructure Management Interface(CIMI), or OpenStack standards. Some IaaS standards may allow clientsaccess to resources over HTTP, and may use Representational StateTransfer (REST) protocol or Simple Object Access Protocol (SOAP).Clients 102 may access PaaS resources with different PaaS interfaces.Some PaaS interfaces use HTTP packages, standard Java APIs, JavaMailAPI, Java Data Objects (JDO), Java Persistence API (JPA), Python APIs,web integration APIs for different programming languages including,e.g., Rack for Ruby, WSGI for Python, or PSGI for Perl, or other APIsthat may be built on REST, HTTP, XML, or other protocols. Clients 102may access SaaS resources through the use of web-based user interfaces,provided by a web browser (e.g. GOOGLE CHROME, Microsoft INTERNETEXPLORER, or Mozilla Firefox provided by Mozilla Foundation of MountainView, Calif.). Clients 102 may also access SaaS resources throughsmartphone or tablet applications, including, for example, SalesforceSales Cloud, or Google Drive app. Clients 102 may also access SaaSresources through the client operating system, including, e.g., Windowsfile system for DROPB OX.

In some embodiments, access to IaaS, PaaS, or SaaS resources may beauthenticated. For example, a server or authentication server mayauthenticate a user via security certificates, HTTPS, or API keys. APIkeys may include various encryption standards such as, e.g., AdvancedEncryption Standard (AES). Data resources may be sent over TransportLayer Security (TLS) or Secure Sockets Layer (SSL).

The client 102 and server 106 may be deployed as and/or executed on anytype and form of computing device, e.g. a computer, network device orappliance capable of communicating on any type and form of network andperforming the operations described herein. FIGS. 1C and 1D depict blockdiagrams of a computing device 100 useful for practicing an embodimentof the client 102 or a server 106. As shown in FIGS. 1C and 1D, eachcomputing device 100 includes a central processing unit 121, and a mainmemory unit 122. As shown in FIG. 1C, a computing device 100 may includea storage device 128, an installation device 116, a network interface118, an I/O controller 123, display devices 124 a-124 n, a keyboard 126and a pointing device 127, e.g. a mouse. The storage device 128 mayinclude, without limitation, an operating system, software, and asoftware of a medical management system (MMS) 120. As shown in FIG. 1D,each computing device 100 may also include additional optional elements,e.g. a memory port 103, a bridge 170, one or more input/output devices130 a-130 n (generally referred to using reference numeral 130), and acache memory 140 in communication with the central processing unit 121.

The central processing unit 121 is any logic circuitry that responds toand processes instructions fetched from the main memory unit 122. Inmany embodiments, the central processing unit 121 is provided by amicroprocessor unit, e.g.: those manufactured by Intel Corporation ofMountain View, Calif.; those manufactured by Motorola Corporation ofSchaumburg, Ill.; the ARM processor and TEGRA system on a chip (SoC)manufactured by Nvidia of Santa Clara, Calif.; the POWER7 processor,those manufactured by International Business Machines of White Plains,N.Y.; or those manufactured by Advanced Micro Devices of Sunnyvale,Calif. The computing device 100 may be based on any of these processors,or any other processor capable of operating as described herein. Thecentral processing unit 121 may utilize instruction level parallelism,thread level parallelism, different levels of cache, and multi-coreprocessors. A multi-core processor may include two or more processingunits on a single computing component. Examples of a multi-coreprocessors include the AMD PHENOM IIX2, INTEL CORE i5 and INTEL CORE i7.

Main memory unit 122 may include one or more memory chips capable ofstoring data and allowing any storage location to be directly accessedby the microprocessor 121. Main memory unit 122 may be volatile andfaster than storage 128 memory. Main memory units 122 may be Dynamicrandom access memory (DRAM) or any variants, including static randomaccess memory (SRAM), Burst SRAM or SynchBurst SRAM (BSRAM), Fast PageMode DRAM (FPM DRAM), Enhanced DRAM (EDRAM), Extended Data Output RAM(EDO RAM), Extended Data Output DRAM (EDO DRAM), Burst Extended DataOutput DRAM (BEDO DRAM), Single Data Rate Synchronous DRAM (SDR SDRAM),Double Data Rate SDRAM (DDR SDRAM), Direct Rambus DRAM (DRDRAM), orExtreme Data Rate DRAM (XDR DRAM). In some embodiments, the main memory122 or the storage 128 may be non-volatile; e.g., non-volatile readaccess memory (NVRAM), flash memory non-volatile static RAM (nvSRAM),Ferroelectric RAM (FeRAM), Magnetoresistive RAM (MRAIVI), Phase-changememory (PRAM), conductive-bridging RAM (CBRAIVI),Silicon-Oxide-Nitride-Oxide-Silicon (SONOS), Resistive RAM (RRAIVI),Racetrack, Nano-RAM (NRAIVI), or Millipede memory. The main memory 122may be based on any of the above described memory chips, or any otheravailable memory chips capable of operating as described herein. In theembodiment shown in FIG. 1C, the processor 121 communicates with mainmemory 122 via a system bus 150 (described in more detail below). FIG.1D depicts an embodiment of a computing device 100 in which theprocessor communicates directly with main memory 122 via a memory port103. For example, in FIG. 1D the main memory 122 may be DRDRAM.

FIG. 1D depicts an embodiment in which the main processor 121communicates directly with cache memory 140 via a secondary bus,sometimes referred to as a backside bus. In other embodiments, the mainprocessor 121 communicates with cache memory 140 using the system bus150. Cache memory 140 typically has a faster response time than mainmemory 122 and is typically provided by SRAM, BSRAM, or EDRAM. In theembodiment shown in FIG. 1D, the processor 121 communicates with variousI/O devices 130 via a local system bus 150. Various buses may be used toconnect the central processing unit 121 to any of the I/O devices 130,including a PCI bus, a PCI-X bus, or a PCI-Express bus, or a NuBus. Forembodiments in which the I/O device is a video display 124, theprocessor 121 may use an Advanced Graphics Port (AGP) to communicatewith the display 124 or the I/O controller 123 for the display 124. FIG.1D depicts an embodiment of a computer 100 in which the main processor121 communicates directly with I/O device 130 b or other processors 121′via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communications technology.FIG. 1D also depicts an embodiment in which local busses and directcommunication are mixed: the processor 121 communicates with I/O device130 a using a local interconnect bus while communicating with I/O device130 b directly.

A wide variety of I/O devices 130 a-130 n may be present in thecomputing device 100. Input devices may include keyboards, mice,trackpads, trackballs, touchpads, touch mice, multi-touch touchpads andtouch mice, microphones, multi-array microphones, drawing tablets,cameras, single-lens reflex camera (SLR), digital SLR (DSLR), CMOSsensors, accelerometers, infrared optical sensors, pressure sensors,magnetometer sensors, angular rate sensors, depth sensors, proximitysensors, ambient light sensors, gyroscopic sensors, or other sensors.Output devices may include video displays, graphical displays, speakers,headphones, inkjet printers, laser printers, and 3D printers.

Devices 130 a-130 n may include a combination of multiple input oroutput devices, including, e.g., Microsoft KINECT, Nintendo Wiimote forthe WII, Nintendo WII U GAMEPAD, or Apple IPHONE. Some devices 130 a-130n allow gesture recognition inputs through combining some of the inputsand outputs. Some devices 130 a-130 n provides for facial recognitionwhich may be utilized as an input for different purposes includingauthentication and other commands. Some devices 130 a-130 n provides forvoice recognition and inputs, including, e.g., Microsoft KINECT, SIRIfor IPHONE by Apple, Google Now or Google Voice Search.

Additional devices 130 a-130 n have both input and output capabilities,including, e.g., haptic feedback devices, touchscreen displays, ormulti-touch displays. Touchscreen, multi-touch displays, touchpads,touch mice, or other touch sensing devices may use differenttechnologies to sense touch, including, e.g., capacitive, surfacecapacitive, projected capacitive touch (PCT), in-cell capacitive,resistive, infrared, waveguide, dispersive signal touch (DST), in-celloptical, surface acoustic wave (SAW), bending wave touch (BWT), orforce-based sensing technologies. Some multi-touch devices may allow twoor more contact points with the surface, allowing advanced functionalityincluding, e.g., pinch, spread, rotate, scroll, or other gestures. Sometouchscreen devices, including, e.g., Microsoft PIXEL SENSE orMulti-Touch Collaboration Wall, may have larger surfaces, such as on atable-top or on a wall, and may also interact with other electronicdevices. Some I/O devices 130 a-130 n, display devices 124 a-124 n orgroup of devices may be augment reality devices. The I/O devices may becontrolled by an I/O controller 123 as shown in FIG. 1C. The I/Ocontroller may control one or more I/O devices, such as, e.g., akeyboard 126 and a pointing device 127, e.g., a mouse or optical pen.Furthermore, an I/O device may also provide storage and/or aninstallation medium 116 for the computing device 100. In still otherembodiments, the computing device 100 may provide USB connections (notshown) to receive handheld USB storage devices. In further embodiments,an I/O device 130 may be a bridge between the system bus 150 and anexternal communication bus, e.g. a USB bus, a SCSI bus, a FireWire bus,an Ethernet bus, a Gigabit Ethernet bus, a Fibre Channel bus, or aThunderbolt bus.

In some embodiments, display devices 124 a-124 n may be connected to I/Ocontroller 123. Display devices may include, e.g., liquid crystaldisplays (LCD), thin film transistor LCD (TFT-LCD), blue phase LCD,electronic papers (e-ink) displays, flexile displays, light emittingdiode displays (LED), digital light processing (DLP) displays, liquidcrystal on silicon (LCOS) displays, organic light-emitting diode (OLED)displays, active-matrix organic light-emitting diode (AMOLED) displays,liquid crystal laser displays, time-multiplexed optical shutter (TMOS)displays, or 3D displays. Examples of 3D displays may use, e.g.stereoscopy, polarization filters, active shutters, or autostereoscopy.Display devices 124 a-124 n may also be a head-mounted display (HIVID).In some embodiments, display devices 124 a-124 n or the correspondingI/O controllers 123 may be controlled through or have hardware supportfor OPENGL or DIRECTX API or other graphics libraries.

In some embodiments, the computing device 100 may include or connect tomultiple display devices 124 a-124 n, which each may be of the same ordifferent type and/or form. As such, any of the I/O devices 130 a-130 nand/or the I/O controller 123 may include any type and/or form ofsuitable hardware, software, or combination of hardware and software tosupport, enable or provide for the connection and use of multipledisplay devices 124 a-124 n by the computing device 100. For example,the computing device 100 may include any type and/or form of videoadapter, video card, driver, and/or library to interface, communicate,connect or otherwise use the display devices 124 a-124 n. In oneembodiment, a video adapter may include multiple connectors to interfaceto multiple display devices 124 a-124 n. In other embodiments, thecomputing device 100 may include multiple video adapters, with eachvideo adapter connected to one or more of the display devices 124 a-124n. In some embodiments, any portion of the operating system of thecomputing device 100 may be configured for using multiple displays 124a-124 n. In other embodiments, one or more of the display devices 124a-124 n may be provided by one or more other computing devices 100 a or100 b connected to the computing device 100, via the network 104. Insome embodiments software may be designed and constructed to use anothercomputer's display device as a second display device 124 a for thecomputing device 100. For example, in one embodiment, an Apple iPad mayconnect to a computing device 100 and use the display of the device 100as an additional display screen that may be used as an extended desktop.One ordinarily skilled in the art will recognize and appreciate thevarious ways and embodiments that a computing device 100 may beconfigured to have multiple display devices 124 a-124 n.

Referring again to FIG. 1C, the computing device 100 may comprise astorage device 128 (e.g. one or more hard disk drives or redundantarrays of independent disks) for storing an operating system or otherrelated software, and for storing application software programs such asany program related to the software for the medical monitoring system120. Examples of storage device 128 include, e.g., hard disk drive(HDD); optical drive including CD drive, DVD drive, or BLU-RAY drive;solid-state drive (SSD); USB flash drive; or any other device suitablefor storing data. Some storage devices may include multiple volatile andnon-volatile memories, including, e.g., solid state hybrid drives thatcombine hard disks with solid state cache. Some storage device 128 maybe non-volatile, mutable, or read-only. Some storage device 128 may beinternal and connect to the computing device 100 via a bus 150. Somestorage device 128 may be external and connect to the computing device100 via a I/O device 130 that provides an external bus. Some storagedevice 128 may connect to the computing device 100 via the networkinterface 118 over a network 104, including, e.g., the Remote Disk forMACBOOK AIR by Apple. Some client devices 100 may not require anon-volatile storage device 128 and may be thin clients or zero clients102. Some storage device 128 may also be used as an installation device116, and may be suitable for installing software and programs.Additionally, the operating system and the software can be run from abootable medium, for example, a bootable CD, e.g. KNOPPIX, a bootable CDfor GNU/Linux that is available as a GNU/Linux distribution fromknoppix.net.

Client device 100 may also install software or application from anapplication distribution platform. Examples of application distributionplatforms include the App Store for iOS provided by Apple, Inc., the MacApp Store provided by Apple, Inc., GOOGLE PLAY for Android OS providedby Google Inc., Chrome Webstore for CHROME OS provided by Google Inc.,and Amazon Appstore for Android OS and KINDLE FIRE provided byAmazon.com, Inc. An application distribution platform may facilitateinstallation of software on a client device 102. An applicationdistribution platform may include a repository of applications on aserver 106 or a cloud 108, which the clients 102 a-102 n may access overa network 104. An application distribution platform may includeapplication developed and provided by various developers. A user of aclient device 102 may select, purchase and/or download an applicationvia the application distribution platform.

Furthermore, the computing device 100 may include a network interface118 to interface to the network 104 through a variety of connectionsincluding, but not limited to, standard telephone lines LAN or WAN links(e.g., 802.11, T1, T3, Gigabit Ethernet, Infiniband), broadbandconnections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet,Ethernet-over-SONET, ADSL, VDSL, BPON, GPON, fiber optical includingFiOS), wireless connections, or some combination of any or all of theabove. Connections can be established using a variety of communicationprotocols (e.g., TCP/IP, Ethernet, ARCNET, SONET, SDH, Fiber DistributedData Interface (FDDI), IEEE 802.11a/b/g/n/ac CDMA, GSM, WiMax and directasynchronous connections). In one embodiment, the computing device 100communicates with other computing devices 100′ via any type and/or formof gateway or tunneling protocol e.g. Secure Socket Layer (SSL) orTransport Layer Security (TLS), or the Citrix Gateway Protocolmanufactured by Citrix Systems, Inc. of Ft. Lauderdale, Fla. The networkinterface 118 may comprise a built-in network adapter, network interfacecard, PCMCIA network card, EXPRESSCARD network card, card bus networkadapter, wireless network adapter, USB network adapter, modem or anyother device suitable for interfacing the computing device 100 to anytype of network capable of communication and performing the operationsdescribed herein.

A computing device 100 of the sort depicted in FIGS. 1B and 1C mayoperate under the control of an operating system, which controlsscheduling of tasks and access to system resources. The computing device100 can be running any operating system such as any of the versions ofthe MICROSOFT WINDOWS operating systems, the different releases of theUnix and Linux operating systems, any version of the MAC OS forMacintosh computers, any embedded operating system, any real-timeoperating system, any open source operating system, any proprietaryoperating system, any operating systems for mobile computing devices, orany other operating system capable of running on the computing deviceand performing the operations described herein. Typical operatingsystems include, but are not limited to: WINDOWS 2000, WINDOWS Server2012, WINDOWS CE, WINDOWS Phone, WINDOWS XP, WINDOWS VISTA, and WINDOWS7, WINDOWS RT, and WINDOWS 8 all of which are manufactured by MicrosoftCorporation of Redmond, Wash.; MAC OS and iOS, manufactured by Apple,Inc. of Cupertino, Calif.; and Linux, a freely-available operatingsystem, e.g. Linux Mint distribution (“distro”) or Ubuntu, distributedby Canonical Ltd. of London, United Kingdom; or Unix or other Unix-likederivative operating systems; and Android, designed by Google, ofMountain View, Calif., among others. Some operating systems, including,e.g., the CHROME OS by Google, may be used on zero clients or thinclients, including, e.g., CHROMEBOOKS.

The computer system 100 can be any workstation, telephone, desktopcomputer, laptop or notebook computer, netbook, ULTRABOOK, tablet,server, handheld computer, mobile telephone, smartphone or otherportable telecommunications device, media playing device, a gamingsystem, mobile computing device, or any other type and/or form ofcomputing, telecommunications or media device that is capable ofcommunication. The computer system 100 has sufficient processor powerand memory capacity to perform the operations described herein. In someembodiments, the computing device 100 may have different processors,operating systems, and input devices consistent with the device. TheSamsung GALAXY smartphones, e.g., operate under the control of Androidoperating system developed by Google, Inc. GALAXY smartphones receiveinput via a touch interface.

In some embodiments, the computing device 100 is a gaming system. Forexample, the computer system 100 may comprise a PLAYSTATION 3, orPERSONAL PLAYSTATION PORTABLE (PSP), or a PLAYSTATION VITA devicemanufactured by the Sony Corporation of Tokyo, Japan, a NINTENDO DS,NINTENDO 3DS, NINTENDO WII, or a NINTENDO WIT U device manufactured byNintendo Co., Ltd., of Kyoto, Japan, an XBOX 360 device manufactured bythe Microsoft Corporation of Redmond, Wash.

In some embodiments, the computing device 100 is a digital audio playersuch as the Apple IPOD, IPOD Touch, and IPOD NANO lines of devices,manufactured by Apple Computer of Cupertino, Calif. Some digital audioplayers may have other functionality, including, e.g., a gaming systemor any functionality made available by an application from a digitalapplication distribution platform. For example, the IPOD Touch mayaccess the Apple App Store. In some embodiments, the computing device100 is a portable media player or digital audio player supporting fileformats including, but not limited to, MP3, WAV, M4A/AAC, WMA ProtectedAAC, AIFF, Audible audiobook, Apple Lossless audio file formats and.mov, .m4v, and .mp4 MPEG-4 (H.264/MPEG-4 AVC) video file formats.

In some embodiments, the computing device 100 is a tablet e.g. the IPADline of devices by Apple; GALAXY TAB family of devices by Samsung; orKINDLE FIRE, by Amazon.com, Inc. of Seattle, Wash. In other embodiments,the computing device 100 is a eBook reader, e.g. the KINDLE family ofdevices by Amazon.com, or NOOK family of devices by Barnes & Noble, Inc.of New York City, N.Y.

In some embodiments, the communications device 102 includes acombination of devices, e.g. a smartphone combined with a digital audioplayer or portable media player. For example, one of these embodimentsis a smartphone, e.g. the IPHONE family of smartphones manufactured byApple, Inc.; a Samsung GALAXY family of smartphones manufactured bySamsung, Inc; or a Motorola DROID family of smartphones. In yet anotherembodiment, the communications device 102 is a laptop or desktopcomputer equipped with a web browser and a microphone and speakersystem, e.g. a telephony headset. In these embodiments, thecommunications devices 102 are web-enabled and can receive and initiatephone calls. In some embodiments, a laptop or desktop computer is alsoequipped with a webcam or other video capture device that enables videochat and video call.

In some embodiments, the status of one or more machines 102, 106 in thenetwork 104 is monitored, generally as part of network management. Inone of these embodiments, the status of a machine may include anidentification of load information (e.g., the number of processes on themachine, CPU and memory utilization), of port information (e.g., thenumber of available communication ports and the port addresses), or ofsession status (e.g., the duration and type of processes, and whether aprocess is active or idle). In another of these embodiments, thisinformation may be identified by a plurality of metrics, and theplurality of metrics can be applied at least in part towards decisionsin load distribution, network traffic management, and network failurerecovery as well as any aspects of operations of the present solutiondescribed herein. Aspects of the operating environments and componentsdescribed above will become apparent in the context of the systems andmethods disclosed herein.

B. Systems and Methods for Medical Dispensing, Management and Monitoring

The present disclosure relates to systems and methods for medicaldispensing, management and monitoring. According to one aspect, a remotemedical management environment can include a medical management systemintermediary to a plurality of patients and a plurality of medical careproviders. The medical management system can communicate with medicaldispensing devices configured to dispense medication to patients.Further, the medical management system can communicate with providerdevices through which medical care providers can access medicine relatedinformation of patients and provide instructions, which can administertreatment protocols to patients of the medical dispensing devices. Theremote medical management environment can allow medical care providers,such as doctors, the ability to remotely manage and administermedications to patients, while at the same time, avoid medicinal drugabuse by patients.

FIG. 2 is a block diagram depicting a medical management environmentincluding a medical management system 120 intermediary to a plurality ofpatient devices 302A-302N and provider devices 402A-402N. The medicalmanagement system 120 can communicate with the plurality of patientdevices 302 via one or more networks. Similarly, the medical managementsystem 120 can also communicate with the plurality of provider devices302 via one or more networks. The medical management system 120 caninclude one or more processors 204, memory 206, one or more patientdatabases 210, one or more provider databases 212, a medical manager 220and a prescription manager 222. The medical management system 120 canalso communicate with one or more third-party data sources 240, forexample, weather databases, location databases, pharmaceutical drugdatabases, pharmacy databases, among others.

The patient database 210 can include one or more tables storinginformation related to one or more patients and their correspondingpatient devices. The patient database can include information relatingto one or more patients registered with the medical management system120. In some implementations, the patient database can store, for eachpatient, one or more of the patient's name, the patient's identifierunique to the patient, the patient's date of birth, a phone number ofthe patient, home and work addresses of the patient, information relatedto the patient's medical records, for example, medical history, medicaldiagnosis, medical treatments, among others. In addition, the databasecan include prescription information for the patient, dosageinformation, allergies of the patient, medical care provider's name,pharmacy name, address and phone number, prescription information,health insurance information, among others. The patient database canalso include a patient device identifier unique to the patient deviceand associated with the patient. The patient database can be maintainedby the medical management system 120. In some implementations, themedical management system 120 can periodically update the patientdatabase. In some implementations, each time the medical managementsystem 120 receives information from a provider device 402 of a medicalcare provider or a patient device 302 of a patient, the medicalmanagement system 120 can identify the patient to which the informationcorresponds and update the patient database 210 to update an entry ofthe patient to include the received information.

The provider database 212 can include one or more tables storinginformation related to one or more medical care providers. The patientdatabase can include information relating to one or more medical careproviders registered with the medical management system 120 to manageand monitor patients and their medications via the medical managementsystem 120. In some implementations, the provider database 212 canstore, for each provider, one or more of the provider's name, theprovider's identifier unique to the provider, the provider's date ofbirth, a phone number of the provider, home and work addresses of theprovider, information related to the provider's medical licensinginformation, among others. In addition, the provider database 212 caninclude a list of patients the medical provider is authorized to treatvia the medical management system 120. The provider database 212 can bemaintained by the medical management system 120. In someimplementations, the medical management system 120 can periodicallyupdate the provider database 212. In some implementations, each time themedical management system 120 receives information from a providerdevice 402 of a medical care provider or a patient device 302 of apatient, the medical management system 120 can identify the medical careprovider to which the information corresponds and update the providerdatabase 212 to update an entry of the provider to include the receivedinformation.

The medical manager 220 can include hardware, software or a combinationand hardware and software. The medical manager 220 can be a script,program, file, or other software construct, which when executed by theprocessor 204, can be configured to communicate with one or more patientdevices 302 and one or more provider devices 402. The medical manager220 can be configured to allow a provider device 402 to remotelydispense, manage and monitor medications provided to a patient via apatient device 302.

The medical manager 220 can be configured to establish communicationswith the provider device 402. In some implementations, the medicalmanager 220 can initiate a request to communicate with the providerdevice 402. In some implementations, the medical manager 220 caninitiate a request to communicate with the provider device 402 inresponse to a triggering event, for example, receiving a communicationrequest from a patient or a patient device, determining that a patientdevice is running low on a prescription medication, identifying that apatient of the provider needs the provider's attention, among others. Insome implementations, the medical manager 220 can receive a request fromthe provider device to establish a communication link with the medicalmanager 220. The provider may submit a request via the provider deviceto access a provider dashboard through which the provider can monitorthe status of patients and the associated patient devices 302.

The medical manager 220 can be configured to provide a user interface tothe provider device 402. In some implementations, the medical manager220 can be configured to receive a request from the provider device 402to access information related to a patient. The request can includeidentifying information of the medical care provider. The medicalmanager 220 can perform a lookup in the provider database 212 tovalidate the identity of the medical care provider and to authenticatethe provider device 402 from which the request was received. The medicalmanager 220 can identify a patient device to which the provider 220requests access. In some implementations, the medical manager 220 canidentify the patient device from the request from the provider device402. In some implementations, responsive to authenticating the providerdevice 402, the medical manager 220 can provide a dashboard on a userinterface of the provider device through which the medical care providercan access information related to one or more patients of the medicalcare provider. In some implementations, the medical manager 220 canreceive a request to access information related to a patient from theprovider device. In some implementations, the medical manager 220 canidentify one or more conditions that can cause the medical manager 220to trigger a notification to the provider device of the medical careprovider. The notification can be specific to a particular patient. Forexample, responsive to the medical manager determining that a patientdevice is running out of a medication, the medical manager 220 cangenerate a notification to the provider device of the medical careprovider of the patient associated with the patient device 302 to notifythe medical care provider to put in a request to refill the prescriptionmedication.

The medical manager 220 can be configured to retrieve or receiveinformation from the patient devices associated with patients subscribedto the medical management system 120. The medical manager 220 canidentify, for each patient device 302, which medications are configuredto be dispensed via the patient devices, the times at which medicationsare dispensed, the type and amount of medication in each channel orcartridge of the patient device, as well as other information relatingto the patient device. In some implementations, the medical manager 220can receive location information identifying a location of the patientdevice, a temperature within each of the medicine cartridges of thepatient device, an ambient temperature around the patient device, amongothers.

The medical manager 220 can be configured to also receive additionalinformation related to each of the patients. In some implementations,the medical management system 120 can communicate with other devicesassociated with the patient, including wearable devices that may providephysiological feedback or data to the medical management system 120. Insome implementations, the wearable devices can measure body temperature,heart rate, breathing rate, oxygen volume, sugar levels, pH levels influids, among others.

The medical manager 220 can be configured to communicate with a patientcommunication device, such as a patient's smartphone or tablet, throughwhich the medical manager 220 can be configured to send notifications tothe patient reminding them to take their medications or to perform oneor more tasks. In some implementations, the medical manager 220 can beconfigured to receive data provided by the patient via the patientcommunication device. In some implementations, the medical manager 220can establish a communication link with the patient communicationdevice, which can serve as a hub for one or more wearable devicesmonitoring physiological and other data of the patient as well as thepatient device 302.

The medical manager 220 can be configured to actuate one or morecomponents of the patient device 302. In some implementations, themedical manager 220 can be configured to send instructions to thepatient device 302, which when executed by a processor of the patientdevice 302, can cause one or more valves or other actuators of thepatient device 302 to dispense medications. In some implementations, theinstructions can specify a length of time for which to keep the valvesopen to ensure that a specific amount of medication is dispensed. Insome implementations, the medical manager 220 can be configured to sendinstructions to regulate the temperature around one or more of thecartridges within which the medications are stored. In someimplementations, the medical manager 220 can send instructions toprovide cooling to cartridges that include medications that need to bemaintained at temperatures below the ambient temperature of the patientdevice 302 or provide heating to cartridges that include medicationsthat need to be maintained at temperatures above the ambient temperatureof the patient device 302.

The medical manager 220 can be configured to maintain and update recordsfor each patient device. In some implementations the medical manager 220can monitor and track the dispensing of medications to the patient ofthe patient device. The medical manager 220 can store the medicationdispensing activity in one or more databases, such as the patientdatabase. In some implementations, the medical manager 220 can monitorand track a time at which the medication was dispensed, an amount ofmedication dispensed, physiological and other patient relatedmeasurements around the time the medication was dispensed, a location atwhich the medication was dispensed, among others. In someimplementations, the medical manager 220 can store this information eachtime medication is dispensed. In some implementations, the patientdevice may take over the function of monitoring and tracking medicationdispensing activity and provide the information to the medical manager220, which can then update the records of the patient device 302 in thepatient database 210.

The prescription manager 222 can be configured to manage prescriptionsof the patients subscribed to the medical management system 120. Theprescription manager 222 can be configured to monitor the amounts ofmedications remaining in the patient devices such that when one or moremedications are running low, the prescription manager 222 can beconfigured to submit requests to the medical care provider and/or one ormore pharmacies to refill the prescription. In some implementations, theprescription manager 222 can be configured to automatically submitrequests to pharmacies for refills. In some implementations, theprescription manager 222 can utilize health insurance information of thepatient stored in the patient database 210 to submit orders forprescriptions to the pharmacies. The prescription manager 222 can beconfigured to identify the one or more medications included in each ofthe cartridges of the patient device. The prescription manager 222 canutilize one or more content sources to determine if any of themedications counteracts with one of the remaining medications in thecartridges or if they include ingredients, compounds, or medicationsthat the patient is allergic to.

Referring now also to FIG. 3, FIG. 3 is a block diagram depicting apatient device configured to dispense medication to a patient. Thepatient device or medical dispensing device 302 includes one or moreprocessors 304, memory 306 and at least one communication module 308.The communication module 308 can include a Bluetooth module 310, a GPSmodule 312, a RFID module 314 and a WiFi module 316. In someimplementations, the communication module 308 can include cellularcommunications module that allows the medical dispensing device 302 tocommunicate with the medical management system 120 via cellularnetworks.

The medical dispensing device 302 can communicate with the medicalmanagement system 120 via one or more networks. The medical dispensingdevice 302 can communicate with the medical management system 120 viaBluetooth, WiFi, a wired internet connection, cellular networks, orother communication channels. In some implementations, the medicaldispensing device 302 can communicate with the medical management system120 using a patient's smartphone or other device as an intermediary. Insome implementations, the medical dispensing device 302 can establish aBluetooth connection with the patient's mobile device and the patient'smobile device can establish a connection with the medical dispensingdevice 302 via one or more cellular, wired or wireless internetnetworks. In some implementations in which the medical dispensing device302 utilizes a Bluetooth network, the medical dispensing device 302 mayoperate within a communication range of a paired device, for example, amobile phone, that is in communication with the medical managementsystem 120.

The medical dispensing device 302 also includes an ID module 318configured to validate communication requests received from otherdevices. This can serve as a security measure to prevent unauthorizeddevices from tampering with the medical dispensing device 302 as well asattempting to access health related information of one or more patientsthat subscribe to the medical management system 120. The ID module 318can also be configured to validate the identity of the patient to whichthe medical dispensing device 302 is assigned. In some implementations,the ID module 318 can include a fingerprint reader or scanner to receivefingerprint information from the patient and determine if the receivedfingerprint information matches the patient. Similarly, the ID module318 can include an iris scanner to validate the identity of the patient.In some implementations, the ID module 318 can include a camera forfacial recognition based on one or more facial features of the patient.In some implementations, the ID module 318 can validate a patient basedon voice recognition. In some implementations, the ID module 318 canvalidate a patient based on voice recognition. In some implementations,the ID module 318 can validate a patient via a communication linkestablished with a trusted device, such as a smartphone or tablet. Insome implementations, the patient can be required to enter a passcode orset of unique characters or gestures on a mobile device in communicationwith the medical dispensing device.

In some implementations, the medical dispensing device may be configuredto communicate with a mobile device of the patient to verify theidentity of a person accessing or requesting access to the medicaldispensing device. For instance, the medical dispensing device may onlydispense medication in response to receiving a communication or signalfrom a paired mobile device that can generate the communication orsignal upon verifying the identity of the patient. In someimplementations, the mobile device can verify the identity of thepatient through facial recognition, fingerprint scanning, passwords, orother security measures that can be received, identified or otherwiseincorporated via the mobile device. In this way, there is no need forthe medical dispensing device to be designed with an integratedfingerprint scanner, camera to detect facial recognition, or keypad toreceive a password from the patient, thereby reducing manufacturingcosts of the medical dispensing device.

The medical dispensing device can be tamper proof. This is to preventmedication abuse and fraud. In some implementations, the medicaldispensing device 320 can include an alert system that triggers an alertupon determining that the medical dispensing device has been tampered oran attempt to tamper the medical dispensing device was made. In someimplementations, the medical dispensing device 320 can include one ormore security modules. The security modules can include hardware andsoftware to ensure that the medication is dispensed to an authorizeduser or patient. In some implementations, the medical dispensing devicecan include a user recognition or identification system. In someimplementations, the medical dispensing device can include a fingerprintreader, an iris scanner, or any other biometric scanner to confirm theidentity of the user. In some implementations, the medical dispensingdevice can be password protected. In some implementations the medicaldispensing device can only be actuated via a second device, such as asmartphone or tablet, registered with the medical management system.

In some implementations, the location of the medical dispensing deviceor the mobile device with which the medical dispensing device cancommunicate may be monitored. In some implementations, one or morelocation based policies can be established to ensure additionalsecurity. For instance, the medical dispensing device may be configuredto only dispense the medicine at predetermined locations, for example, apatient's home, a patient's work location, a hospital or other medicalcare provider's address, among others. In this way, if the device isstolen or otherwise provided to an unauthorized user, the unauthorizeduser may be unable to receive medication from the medical dispensingdevice at locations different from the predetermined locations. Inaddition, the medical dispensing device may only transmit or receivedata from the medical management system at the predetermined locationsto reduce security breaches.

The medical dispensing device 302 also includes one or more cartridgesthat contain medications to be dispensed. The cartridges can beremovable from the medical dispensing device 302. In someimplementations, the cartridges can be refilled. The cartridges can beshaped and sized to match an opening in the medical dispensing deviceand may include one or more identifying labels, tags, or other readableor detectable information that the medical dispensing device can read,identify or otherwise detect to ensure the authenticity of thecartridge. This can be used to prevent counterfeit medications ormedications provided by unauthorized medical providers. In someimplementations, the pharmacy providing the cartridge may include anRFID tag to the cartridge that is encrypted. In some implementations,the cartridge can be tagged in such a way that the cartridge's RFID tagcan only be identified by the medical dispensing device associated withthe patient for which the medication in the cartridge is prescribed. Insome implementations, the cartridge can be made tamper proof such thatif an unauthorized attempt to open or otherwise access or damage thecartridge is made, the medication inside the cartridge is destroyed orotherwise tainted or damaged that the medication loses any monetaryvalue to discourage the resale of the medication or the abuse orunprescribed use of the medication. In some implementations, an acid orother compound that destroys the medication may be exposed to themedication.

The medical dispensing device can include one or more slots or channelswithin which the cartridges are insertable. Each slot can include atemperature controller 340 that is configured to regulate thetemperature of the cartridge inserted within the slot. In someimplementations, the temperature controller can include a thermoelectriccooler or a heater that can be configured to decrease or increase thetemperature of the cartridge or the contents of the cartridge.

The medical dispensing device 302 can include one or more actuators 322a-322 n that are configured to actuate a switch, valve or otherregulator that controls the amount of medication that is dispensed fromthe respective cartridge. The actuators can be configured to allow acertain amount of medication to be dispensed on a per unit time basis.In some implementations, the amount of medication dispensed per unittime may be altered based on various factors, including a size of anopening, the configuration of the actuator, and the amount of time theopening is kept open.

The actuators 332 of the medical dispensing device 302 can be configuredto be remotely controlled by the medical manager 220 of the medicalmanagement system 120. In some implementations, the medical manager 220can be configured to provide dosage instructions to the medicaldispensing device 302 and the processor 304 can be configured to causethe actuators of the corresponding cartridges to be actuated in such away that the amount of medications dispensed from the cartridges isequivalent to the desired dosage prescribed by the medical careprovider. The actuators can be electronically controlled. In someimplementations, the actuators can be powered via an on-board battery.In some implementations, the on-board battery can be rechargeable.

In some implementations, the medical dispensing device can operate usingbatteries. In some implementations, the batteries may be rechargeable ordisposable. In some implementations in which the batteries arerechargeable, the batteries may be charged via a USB cable, via a powersupply channel, or via wireless induction. In some implementations, toimplement wireless induction, the medical dispensing device can beincorporated with a wireless charging coil, for example, a wirelesscharging coil supplied by DIGIKEY and manufactured by Wurth Electronics,Inc. In some implementations, the wireless charging coil can be PartNumber 76030811, manufactured by Wurth Electronics, Inc. The shape, sizeand position of the one or more wireless charging coils can be designedto fit within the medical dispensing device.

The medical dispensing device 302 can include one or more sensors forsensing or monitoring the amount of medication dispensed from each ofthe cartridges. In some implementations, the sensors can monitor aweight of medication dispensed or a weight of medication remaining inthe cartridge after medication is dispensed. In some implementations,the sensors can count a number of pills dispensed. In someimplementations, the sensors can monitor a time for which a valve isleft open and a flow rate of the medication flowing through the valve.The medical dispensing device can include sensors measuring a quantityof medication remaining in the medical dispensing device. In someimplementations, the medical dispensing device can determine an amountof medication remaining in the medical dispensing device based on theamount of medication included in a medicine cartridge and an amount ofmedication already dispensed since the medicine cartridge was firstinserted. The medical dispensing device can be configured to communicatemedicine quantity levels to the medical management system 120 such thatthe medical management system 120 can submit orders for refills to oneor more pharmacies before the medicine cartridge is completely empty.

The medical dispensing device 302, via the processor 304, can maintain amonitoring log storing information related to the monitoring of themedical dispensing device 302. The monitoring log can store informationrelated to communications received from the medical management system120. The log can store event related information. Examples of eventsinclude a medicine dispensing event, a medical care provider device ormedical management system establishing communications with the medicaldispensing device, an alarm triggering event (in the event of an attemptto tamper the medical dispensing device), location changes of themedical dispensing device, changes to ambient conditions of the medicaldevice, for example, when the medical dispensing device senses atemperature below or above one or more predefined temperatures,detecting low medication levels in one or more cartridges of the medicaldispensing device 302, among others. The activity logs can identify adate and time at which medication was dispensed, a dosage of medicationdispensed as well as any other physiological measurements, for example,temperature, pulse, heart rate, blood pressure, sugar levels, amongothers, taken around the time the medication was dispensed. In additionto medication dispensing related activity, the activity logs canidentify when a medical care provider communicated with the medicaldispensing device. In some implementations, the activity logs caninclude information related to dosage changes as well as changes in thetime at which medication is to be administered.

The medical dispensing device includes an outlet port or opening 330through which medications within the cartridges are dispensed from themedical dispensing device. The outlet opening 330 can be configured toallow a patient to administer the medication orally. In someimplementations, the opening 330 can be configured to allow medicationto be dispensed in such a way that a patient can apply the medicationtopically, subcutaneously, pulmonary or intravenously, among others.

The patient device, otherwise referred to as a medical dispensing devicecan be configured to allow a medical care provider, for example, adoctor, the ability to remotely monitor, regulate and manipulatemedication administration to a patient associated with the patientdevice. Through the medical dispensing device, the medical care providercan adjust either the dosage of medications or the time at which themedication is administered. In some implementations, the medical careprovider may receive feedback through the medical dispensing device orother medical device monitoring the patient and adjust the dosage ortime at which to administer medication based on the received feedback.The medical dispensing device can be equipped with a communicationsmodule that is configured to communicate with the medical managementsystem through which the medical care provider can remotely communicatewith the medical dispensing device. The communications module caninclude both hardware and software components that allow the medicaldispensing device to receive and transmit instructions and information.In some implementations, the communications module can be configured toprovide wireless communications, for example, BLUETOOTH, WiFi, cellularcommunications, among others. In some implementations, thecommunications module can be configured to communicate with anotherdevice, such as a smartphone, tablet, or other device that allows themedical dispensing device to receive and execute instructions receivedfrom the medical care provider.

In some implementations, the medical dispensing device can include atemperature control module to control the temperature of medicationwithin the medical dispensing device. In this way, if the medicine inthe medical dispensing device is to be maintained at a particulartemperature, and the medical dispensing device is in a location that hasan ambient temperature much higher than the temperature at which tomaintain the medicine, the medical dispensing device can provide coolingto the medication. Conversely, the medical dispensing device can provideheating to medications that are supposed to be stored or maintained attemperatures higher than the ambient temperature at which the medicaldispensing device is located.

In some implementations, the medical dispensing device 302 can include athermoelectric cooler, such as one manufactured by CUSTOM THERMOELECTRICof Bishopville, Md., USA. In some implementations, the thermoelectriccooler can be Part #03201-9G30-08RA manufactured by CUSTOMTHERMOELECTRIC or other similar thermoelectric cooler. In someimplementations, the medical dispensing device 302 can include one ormore heat or cooling tanks that may be positioned adjacent to or aroundone or more cartridges of the medical dispensing device 302. In someimplementations, the heating or cooling mechanism can use convection,conduction or radiation. In some implementations, a small convectionsystem may be used to carry air from the thermoelectric cooler to a topportion of the medical dispensing device where the air will be dispersedto the atmosphere. As such, the medical dispensing device 302 mayinclude one or more vents through which air can enter and exit themedical dispensing device.

In some implementations, the thermoelectric cooler can be part of themedical dispensing device. In some implementations, the thermoelectriccooler can be part of the cartridge that may be removable from themedical dispensing device. In some implementations in which thethermoelectric cooler is part of the cartridge, the thermoelectriccooler can be positioned within the cartridge in such a way that whenthe cartridge is inserted in the medical dispensing device, thethermoelectric cooler can be coupled to a power source of the medicaldispensing device that can provide power to the thermoelectric cooler.In some implementations in which the thermoelectric cooler is part ofthe medical dispensing device, the thermoelectric cooler can beconfigured or positioned in such a way that the thermoelectric coolercan provide heating or cooling to the cartridge and its contents.

In some implementations, the medical dispensing device can utilize afluid channel that includes a thermally conductive fluid, such asalcohol. The fluid channel can be positioned to extend along a side ofthe medical dispensing device. The fluid channel can be configured tocause heat to dissipate from around the cartridges. In someimplementations, the fluid channel can be configured to provide acooling effect similar to how laptop coolers dissipate heat generated bylaptops.

In some implementations, a temperature sensor positioned within, near oradjacent to the cartridges can detect the ambient temperature around thecartridge. In some implementations, the ambient temperature may be basedon weather databases based on location. In some implementations, thelocation of the medical dispensing device 302 can be determined from aGPS module or cellular module of the medical dispensing device 302. Insome implementations, the medical dispensing device 302 can beconfigured or otherwise programmed to activate the cooling or heatingsystems of the medical dispensing device to maintain the temperaturearound the cartridges at temperatures suitable for storing themedications.

In some implementations, the medical dispensing device 302 can includeone or more audio output components, such as a speaker, configured toemit alerts or transmit voice commands to the patient. In someimplementations, the medical dispensing device 302 can communicate witha wireless or wired headphone or speaker to provide voice or audionotifications to the patient. In some implementations, the medicaldispensing device 302 can include a microphone through which the patientcan communicate with a medical care provider. In this way, patients thathad vision or hearing impaired, may be able to locate the medicaldispensing device 302 as well as receive instructions from a medicalcare provider remotely. In some implementations, the medical dispensingdevice 302 can include a screen through which a patient who has impairedhearing can receive instructions.

In some implementations, the medical dispensing device 302 can also beconfigured to include one or more input channels through which themedical dispensing device can receive input data from one or morewearable or portable measurement devices measuring physiological andother metrics of the patient. The data received from the measurementdevices can be used by the medical dispensing device 302 to administermedication to the patient. In some implementations, the medicaldispensing device 302 can utilize one or more medicine administrationpolicies according to which dosages are administered. These policies canbe established by a medical care provider of the patient and provided tothe medical dispensing device 302 via the medical management system 120.

In some implementations, the medical dispensing device can be configuredto report the measured data to the medical management system 120. Themedical dispensing device can report the measured data periodically orupon a detected triggering event (for example, if the blood sugar leveldrops below a certain level, or a pulse rate or breathing rate dropsbelow or exceeds a predefined level). The medical management system 120can be configured to identify triggering events based on the datareceived and may initiate a communication with the medical care provideralerting the provider of a medical condition.

The medical care provider, via the provider device 402, can sendinstructions to the medical dispensing device to administer medicationto the patient. In some implementations, the provider device 402 canmodify a dosage regimen programmed for the medical dispensing device bysending instructions to the medical dispensing device 302 via themedical management system 120.

FIG. 4 is a block diagram depicting a provider device configured toallow a medical care provider to manage medications of patientsreceiving medication through the patient device of FIG. 3. The providerdevice 402 can include a processor 404, a memory 406, a dosage manager408 and a user interface 410.

The dosage manager 408 can be configured to manage, administer andmonitor dosage information provided to each of the medical dispensingdevices 302 of patients of the medical care provider of the providerdevice 402. The dosage manager 408 can include hardware, software or acombination of both to communicate with each of the medical dispensingdevices 302 via the medical management system 120. The dosage manager408 can receive instructions from the medical care provider via the userinterface 410, which can be provided for display on a display of theprovider device 402. The provider can view patient related data on theuser interface, including but not limited to current dosage levels ofmedications, the identity of medications loaded in the cartridges of themedical dispensing device 302, as well as data from one or moremonitoring devices monitoring patient's vitals, physiological metrics,among others. The provider can send instructions to administer, modifyor otherwise alter dosages to the medical dispensing devices 302. Thedosage manager 408 can receive these instructions and provideinstructions to the medical management system 120 such that the correctdosage can be administered at the medical dispensing device 302.

While the invention has been particularly shown and described withreference to specific embodiments, it should be understood by thoseskilled in the art that various changes in form and detail may be madetherein without departing from the spirit and scope of the inventiondescribed in this disclosure.

While this specification contains many specific embodiment details,these should not be construed as limitations on the scope of anyinventions or of what may be claimed, but rather as descriptions offeatures specific to particular embodiments of particular inventions.Certain features described in this specification in the context ofseparate embodiments can also be implemented in combination in a singleembodiment. Conversely, various features described in the context of asingle embodiment can also be implemented in multiple embodimentsseparately or in any suitable subcombination. Moreover, althoughfeatures may be described above as acting in certain combinations andeven initially claimed as such, one or more features from a claimedcombination can in some cases be excised from the combination, and theclaimed combination may be directed to a subcombination or variation ofa subcombination.

Similarly, while operations are depicted in the drawings in a particularorder, this should not be understood as requiring that such operationsbe performed in the particular order shown or in sequential order, orthat all illustrated operations be performed, to achieve desirableresults. In certain circumstances, multitasking and parallel processingmay be advantageous. Moreover, the separation of various systemcomponents in the embodiments described above should not be understoodas requiring such separation in all embodiments, and it should beunderstood that the described program components and systems cangenerally be integrated in a single software product or packaged intomultiple software products.

References to “or” may be construed as inclusive so that any termsdescribed using “or” may indicate any of a single, more than one, andall of the described terms.

Thus, particular embodiments of the subject matter have been described.Other embodiments are within the scope of the following claims. In somecases, the actions recited in the claims can be performed in a differentorder and still achieve desirable results. In addition, the processesdepicted in the accompanying figures do not necessarily require theparticular order shown, or sequential order, to achieve desirableresults. In certain embodiments, multitasking and parallel processingmay be advantageous.

What is claimed is:
 1. A system, comprising: a processor and a memoryincluding computer-executable instructions, which when executed by theprocessors, causes the processor to: establish, via a network, a firstconnection with a first device and a second connection with a seconddevice; receive, via the network, one or more packets including apayload that includes data measured via one or more sensors of thesecond device; transmit, via the network, the data measured via the oneor more sensors of the second device to the first device; receive, viathe network, a request to securely transmit instructions to a thirddevice, the instructions identifying the second device.